8장 모델 고르기와 사용량 관리 (입문)

원서: 클로드 코드 완벽 가이드 (코드팩토리 최지호)

이 장에서 딱 4가지만 1. Opus와 Sonnet은 뭐가 같고 뭐가 다른지 구분한다. 2. 작업 형태에 맞게 두 모델을 고르는 법을 따라 한다. 3. 세션 시간과 에이전트 수로 사용량을 아끼는 법을 설명한다. 4. /model 명령으로 남은 사용량을 가늠하는 법을 따라 한다.

참고: 여기 나오는 요금·시간·전환 시점 수치는 원서/노트 기준 예시입니다. 최신 값은 공식 문서(클로드 코드 공식 문서)에서 꼭 확인하세요.

들어가며 — 이런 적 있죠?

코딩을 도와주는 AI한테 일을 시켰는데, 점심도 되기 전에 "오늘 사용량을 다 썼어요" 같은 메시지를 만난 적 있나요?

분명 열심히 쓴 것도 아닌데 금방 막힌 느낌.

그게 바로 이 장에서 풀어야 할 문제예요.

원인은 보통 둘 중 하나예요.

하나, 더 똑똑하지만 더 비싼 모델(Opus)을 모든 일에 다 써버렸거나.

둘, 시간을 아무 생각 없이 흘려보내서 정작 집중할 때 쓸 게 남지 않았거나.

이 장은 "어떤 일에 어떤 모델을 쓰고, 시간을 어떻게 배분하면 손해를 덜 보는가"를 알려줘요.

비유하면 이래요.

식당에서 무한리필 이용권을 샀다고 쳐요.

좋은 메뉴만 골라 먹고, 시간 안에 알차게 먹으면 본전을 뽑아요.

반대로 아무거나 집어 먹고 시간을 흘려보내면 손해죠.

모델 고르기와 사용량 관리는 그 "본전 뽑기 기술"이에요.

섹션 1 — 두 모델, 같은 부분부터

막혀본 장면

"AI 모델이 여러 개라는데, 그럼 어떤 건 검색이 되고 어떤 건 안 되나? 뭐가 되고 뭐가 안 되는지 헷갈려."

이렇게 생각해본 적 있을 거예요.

결론부터 말하면, 클로드 코드의 두 주력 모델 Opus와 Sonnet은 기본기가 똑같아요.

그래서 "이 기능은 이 모델만 돼" 같은 걱정은 안 해도 돼요.

용어 한 줄: 모델(model) 은 AI의 두뇌 종류예요. 같은 회사가 만든 두뇌인데 성격이 다른 버전이 여러 개 있다고 보면 돼요.

일상 비유부터, 크게

스포츠카와 세단을 떠올려 보세요.

목적은 달라요. 하나는 빠르게 달리고, 하나는 편하게 많이 태워요.

그런데 에어백, 안전벨트, 후방 카메라, 내비게이션은 둘 다 기본으로 달려 있어요.

Opus(스포츠카)와 Sonnet(세단)도 똑같아요.

성격은 다르지만 아래 네 가지 기본기는 둘 다 가지고 있어요.

둘 다 가진 네 가지 기본기

하나, 하이브리드 추론 모드.

쉬운 질문엔 바로 답하고, 어려운 질문엔 잠깐 더 생각하고 답하는 방식이에요.

용어 한 줄: 하이브리드 추론 모드 는 "빨리 답하기"와 "깊이 생각하고 답하기"를 상황 따라 바꾸는 기능. 시험에서 쉬운 문제는 바로 쓰고 어려운 문제는 메모하며 푸는 것과 같아요.

둘, 병렬 도구 사용.

웹 검색과 다른 작업을 동시에 처리해요.

용어 한 줄: 병렬 도구 사용 은 여러 도구를 동시에 쓰는 것. 라면 끓이면서 동시에 계란 부치는 것과 같아요.

셋, 향상된 지시 따르기와 메모리.

여러 단계로 된 복잡한 지시도 순서대로 잘 따라요. 쓸수록 내 작업 방식도 어느 정도 기억해요.

넷, 200K 토큰 컨텍스트 창.

한 번에 약 15만 단어 분량을 읽고 다룰 수 있어요. 책 한 권을 통째로 펼쳐 놓고 일하는 셈이에요.

용어 한 줄: 토큰(token) 은 AI가 글을 세는 단위. 글자 묶음 한 조각이라고 보면 돼요. 컨텍스트 창 은 한 번에 펼쳐 놓고 볼 수 있는 작업 책상 크기예요.

비유를 바로 연결

비유	클로드 코드에서	주의
차의 기본 안전장치	두 모델 공통 기본기 4가지	"이 기능은 한 모델만 된다"가 아니에요
시험에서 쉬운 문제 바로 풀기	하이브리드 추론의 빠른 응답	어려운 문제엔 자동으로 더 생각해요
책상 크기	200K 컨텍스트 창	책상이 커도 무한은 아니에요. 너무 많이 올리면 차서 넘쳐요

잘못된 예 vs 올바른 예

잘못된 생각: "Opus만 웹 검색이 되고 Sonnet은 안 되겠지?"

→ 아니에요. 네 가지 기본기는 둘 다 있어요.

올바른 생각: "기본기는 같으니까, 고를 때는 '얼마나 똑똑해야 하나 / 얼마나 빨라야 하나'만 따지면 돼."

실제로 보면

빠른 일과 느린 일을 모델이 알아서 구분해요. 명령은 평소처럼 말로 시키면 돼요.

# 간단한 일 → 바로 답해요
"이 변수 이름을 카멜케이스로 바꿔줘"

# 복잡한 일 → 잠깐 더 생각하고 답해요
"이 서비스에서 느려지는 구간을 분석하고 개선안을 알려줘"

한 걸음 더 ▸

200K가 약 15만 단어라고 했는데, 이건 "한 번에 펼칠 수 있는 최대 크기"예요. 한국어 책 한 권 분량보다 넉넉해요. 지금은 "엄청 크다" 정도만 알면 충분해요.

스스로 확인

두 모델의 공통 기본기 4가지를 말할 수 있나요?
하이브리드 추론 모드가 어떻게 두 가지로 작동하는지 설명할 수 있나요?

섹션 2 — 두 모델, 다른 부분 (듀얼 플래그십)

막혀본 장면

"무조건 제일 비싸고 똑똑한 모델만 쓰면 되는 거 아니야?"

이렇게 생각해서 모든 일을 Opus에만 시켰다가, 사용량이 순식간에 바닥난 적 있을 거예요.

그게 바로 "두 모델의 차이를 모르고 쓴" 상황이에요.

일상 비유부터, 크게

미슐랭 셰프에게 라면을 끓여달라고 할 필요는 없어요.

라면은 분식집 사장님이 더 빠르고 알맞게 끓여요.

하지만 프렌치 코스 요리는 미슐랭 셰프에게 맡겨야 제맛이죠.

여기서 미슐랭 셰프가 Opus, 분식집 사장님이 Sonnet 이에요.

둘 다 훌륭한 요리사인데, 잘 맞는 자리가 달라요.

이렇게 "최고 하나"가 아니라 "용도별로 둘"을 두는 방식을 듀얼 플래그십 이라고 불러요.

용어 한 줄: 듀얼 플래그십(dual-flagship) 은 대표 모델을 하나만 두지 않고 성격이 다른 둘을 나란히 두는 전략. 가게에 "추천 메뉴"가 두 개 있는 것과 같아요.

Opus와 Sonnet, 어떻게 다른가

구분	Opus (프런티어 전문가)	Sonnet (고성능 실무자)
자리	가장 똑똑한 쪽	똑똑함·속도·비용의 균형
잘 맞는 일	어려운 추론, 설계, 연구	코딩, 대용량 처리, 실무 앱
속도	상대적으로 느림	상대적으로 빠름
비용	높음 (많이 소모)	효율적 (덜 소모)

용어 한 줄: 프런티어(frontier) 는 "가장 앞선"이라는 뜻. 가장 어려운 일까지 해내는 최상위라는 의미예요.

비유를 바로 연결

비유	클로드 코드에서	주의
미슐랭 셰프	Opus	모든 일에 부르면 비싸요
분식집 사장님	Sonnet	빠르고 효율적이지만 가장 어려운 추론은 Opus가 나아요
추천 메뉴 두 개	듀얼 플래그십	하나만 고집할 필요 없어요. 일에 맞게 골라요

반전 — Opus가 항상 위는 아니에요

여기서 많은 사람이 놀라요.

"코딩 같은 실전 작업"에서는 Sonnet이 Opus보다 살짝 더 나은 결과를 보이기도 해요.

원서 노트의 벤치마크 비교에서 에이전틱 코딩 점수가 Sonnet 쪽이 조금 더 높게 나온 사례가 있어요.

용어 한 줄: 벤치마크(benchmark) 는 모델끼리 같은 시험을 치러 점수를 매기는 비교 시험이에요.

즉 "비쌀수록 항상 좋다"는 편견은 버려야 해요.

실제로 깃허브, Replit, Sourcegraph 같은 기업들이 코딩 작업에 Sonnet을 골라 쓴 사례가 노트에 나와요.

잘못된 예 vs 올바른 예

잘못된 예: 변수명 바꾸기 같은 단순 작업까지 Opus로.

→ 결과 차이는 거의 없는데 사용량만 빨리 닳아요.

올바른 예: 단순 작업은 Sonnet, 진짜 어려운 설계나 추론만 Opus.

미니 시나리오: 오전 내내 가벼운 코드 수정만 하는 날이라면, 굳이 Opus를 켜둘 이유가 없어요. Sonnet으로 두고 가볍게 가세요.

스스로 확인

듀얼 플래그십이 무슨 뜻인지 설명할 수 있나요?
Opus가 Sonnet보다 항상 좋은 건 아닌 사례를 하나 들 수 있나요?
Sonnet을 채택한 기업을 한 곳 이상 말할 수 있나요?

섹션 3 — 고르는 기준 1: 일의 형태 (계획은 Opus, 실행은 Sonnet)

막혀본 장면

처음부터 끝까지 Opus 하나로 밀어붙였는데, 정작 마무리 단계에서 사용량이 동나서 코드를 끝맺지 못한 적 있나요?

그게 바로 "일의 형태에 안 맞게 모델을 쓴" 상황이에요.

일상 비유부터, 크게

집을 짓는다고 해봐요.

설계도는 유명 건축가(Opus)에게 맡겨요. 머리를 많이 써야 하니까요.

하지만 벽돌을 쌓는 실제 시공은 숙련된 현장팀(Sonnet)에게 맡겨요. 설계도만 있으면 빠르고 깔끔하게 해내거든요.

설계까지 현장팀에 맡기면 엉성하고, 벽돌 쌓기까지 건축가가 하면 비싸고 느려요.

핵심 패턴 — 계획과 실행을 나눠요

잘못된 방식: 모든 작업에 Opus만 사용
   → 사용량 빨리 소진, 낭비

올바른 방식: 계획과 실행을 나누기
   [1] Opus로 설계하고 상세 계획 세우기
   [2] Sonnet으로 바꿔서 계획대로 실행
   [3] 버그가 안 풀릴 때만 잠깐 Opus로 복귀

비유를 바로 연결

비유	클로드 코드에서	주의
건축가가 설계도	Opus로 계획 수립	계획 단계는 머리를 많이 써요
현장팀이 시공	Sonnet으로 실행	계획이 있으면 품질 차이가 거의 없어요
막힌 공사 구간 점검	반복 버그만 Opus 복귀	계속 Opus로 두지 말고 다시 Sonnet으로

실제로 보면 (인증 시스템 고치기 시나리오)

# 1단계: Opus로 계획 세우기 (머리 쓰는 단계)
"지금 인증 방식을 다른 방식으로 바꾸는 계획을 세워줘.
 영향받는 파일, 작업 순서, 되돌리기 방법까지 알려줘."
→ Opus가 꼼꼼한 실행 계획을 내놓음

# 2단계: /model로 Sonnet 전환 (실행 단계)
"위 계획의 1번부터 실행해줘."
→ Sonnet이 같은 품질로 더 빠르게 코드 작성

# 3단계: 반복 에러일 때만 Opus 복귀
"이 에러가 세 번째 반복돼. 지금까지 시도한 걸 보고
 근본 원인을 찾아줘."
→ Opus가 핵심 원인 파악 → 다시 Sonnet에 맡김

위에서 /model 은 쓸 모델을 바꾸는 명령이에요. 자세한 사용법은 섹션 6에서 따라 해 볼게요.

잘못된 예 vs 올바른 예

잘못된 예: 계획이 다 나온 뒤에도 단순 CRUD 코드 작성까지 Opus로.

올바른 예: 계획이 확정되면 Sonnet으로 바꿔서 빠르게 찍어내기.

미니 시나리오: 설계가 끝나서 "이제 그대로 만들기만 하면 돼" 하는 순간이 Sonnet 전환 신호예요.

스스로 확인

계획 단계에서 Opus가 유리한 이유를 말할 수 있나요?
실행 단계에서 Sonnet을 쓰는 게 합리적인 이유 두 가지를 말할 수 있나요?
언제 Opus로 돌아가야 하는지 판단할 수 있나요?

섹션 4 — 고르는 기준 2: 작업 시간 (세션 전략)

막혀본 장면

"왜 아침에 잠깐 쓰고 점심때 다시 켰는데 벌써 시간이 부족하지?"

세션이 언제부터 시작되는지를 몰라서 시간을 흘려보낸 거예요.

일상 비유부터, 크게

뷔페에서 2시간 이용권을 샀다고 해봐요.

입장하는 그 순간부터 시간이 흘러요.

들어가서 화장실 갔다 오고 30분을 멍하니 보내면, 그만큼 손해예요.

배고플 때 딱 입장해서 집중해서 먹어야 본전을 뽑죠.

클로드 코드의 세션 도 똑같아요.

용어 한 줄: 세션(session) 은 사용 시간 한 묶음이에요. 노트 기준으로 첫 요청을 보낸 순간부터 5시간 동안 유지돼요. (정확한 시간은 공식 문서에서 확인하세요.)

핵심은 이거예요. 첫 요청을 보낸 그 순간 부터 5시간이 카운트돼요.

비유를 바로 연결

비유	클로드 코드에서	주의
뷔페 입장 순간 시간 시작	첫 요청 순간 세션 시작	가입 시점이 아니라 첫 요청 시점이에요
멍하니 보낸 30분	흘려보낸 세션 시간	안 써도 시간은 흘러요
배고플 때 입장	집중할 시간 직전에 세션 시작	미리 한 번 요청해 세션을 깔아둘 수 있어요

세션 타이밍 전략 (9시~18시 근무 기준)

시간대          활용 전략
─────────────────────────────────────────
08:00           아무 요청이나 보내서 세션 시작!
 ↓               (출근 전 1시간을 미리 깔아둠)
09:00~12:00     [세션 1] Opus 집중 사용
12:00~13:00     점심시간
13:00           새 세션 시작! (시간 다시 초기화)
 ↓
13:00~16:00     [세션 2] Opus 집중 사용
16:00~18:00     Sonnet으로 전환 또는 미팅

핵심: 8시에 시작하면 13시까지 유지!
      13시에 새로 시작하면 18시까지!

실제로 보면 (아침 미팅이 많은 사람)

10:00  미팅 끝나고 첫 요청 전송
       → 세션이 15:00까지 유지됨
13:00~15:00  점심 후 Opus 집중 사용
15:00  세션이 끝나면 새 세션 시작
15:00~18:00  Opus로 추가 사용

잘못된 예 vs 올바른 예

잘못된 예: 출근하자마자 의미 없는 요청을 마구 보내며 시간을 흘려보내기.

올바른 예: 집중해서 쓸 시간 직전에 첫 요청을 한 번 깔아두기.

미니 시나리오: 오후 1시부터 진짜 집중 작업을 하고 싶다면, 점심 직전이나 1시 정각에 첫 요청을 보내 세션을 시작하세요. 그래야 5시간을 온전히 쓸 수 있어요.

한 걸음 더 ▸

여기 나온 "5시간", "하루에 두 세션" 같은 수치는 노트 기준 예시예요. 플랜과 시점에 따라 달라질 수 있으니, 정확한 세션 길이와 한도는 클로드 코드 공식 문서에서 확인하세요. 원리는 "첫 요청 순간부터 시간이 흐른다"는 점만 기억하면 돼요.

스스로 확인

세션 시간이 언제부터 카운트되는지 정확히 아나요?
내 근무 패턴에 맞는 세션 시작 시각을 계산할 수 있나요?
세션 시작 시각을 조절하는 게 왜 중요한지 설명할 수 있나요?

섹션 5 — 고르는 기준 3: 동시에 돌리는 에이전트 수

막혀본 장면

여러 작업을 한꺼번에 빨리 끝내고 싶어서 AI 일꾼을 여러 개 동시에 돌렸는데, 사용량이 평소보다 훨씬 빨리 동난 적 있나요?

그게 바로 "에이전트를 많이 띄워서 사용량이 배로 빠진" 상황이에요.

용어 한 줄: 에이전트(agent) 는 코드를 알아서 읽고 고치고 돌리는 AI 일꾼 하나예요. 여러 개를 동시에 돌릴 수 있어요.

일상 비유부터, 크게

물탱크는 하나인데, 수도꼭지를 세 개 동시에 틀면 물이 세 배로 빨리 빠져요.

물탱크가 사용량(토큰), 수도꼭지가 에이전트예요.

꼭지를 많이 틀수록 시원하긴 한데, 정작 나중에 꼭 필요할 때 물이 없을 수 있어요.

비유를 바로 연결

비유	클로드 코드에서	주의
물탱크 하나	내 사용량(토큰) 한도	에이전트가 많아도 탱크는 하나예요
수도꼭지 여러 개	동시에 돌리는 에이전트	많이 틀수록 빨리 빠져요
물 떨어진 순간	사용량 소진	정작 필요할 때 못 쓸 수 있어요

플랜별로 보면

$100 플랜
  에이전트 1개로 Opus 연속 사용 → 약 2시간
  대부분 상황에서 충분한 수준
  전략: 가장 중요한 순간에만 Opus 집중
        (계획 때만 Opus, 실행 때 Sonnet)

$200 플랜
  에이전트 3개 동시 실행 시 Opus 약 2~3시간
  토큰 걱정을 크게 안 해도 되는 편
  단, 3개를 넘어가면 전략적으로 고민 필요
  PRD/DDL 같은 문맥 작업은 한 곳에서 진행

용어 한 줄: PRD 는 만들 제품의 요구사항을 정리한 문서, DDL 은 데이터베이스 구조를 정의하는 부분이에요. 둘 다 "전체 맥락이 한곳에 모여야 하는 작업"의 예시예요. 여러 에이전트로 쪼개지 말고 한 곳에서 다루라는 뜻이에요.

한 가지 단서 — 큰 플랜의 여유엔 조건이 있어요

위에서 "$200 플랜은 토큰 걱정을 크게 안 해도 되는 편"이라고 했죠.

그런데 여기엔 숨은 조건이 하나 있어요.

바로 "내가 어떻게 쓰느냐"예요.

일상 비유로 볼게요.

뷔페 무한리필을 끊었다고 음식이 정말 무한정 나오는 건 아니에요. 한 사람이 알차게 골라 먹으면 넉넉하지만, 친구 다섯을 불러서 아무거나 마구 집어 담으면 금세 부족해져요.

비유	클로드 코드에서	주의
한 사람이 알차게 골라 먹기	생각하며 모델·에이전트를 고르는 사용	이러면 큰 플랜은 여유 있어요
친구 다섯이 마구 집어 담기	아무 생각 없이 Enter만 누르며 마구 돌리기	이러면 큰 플랜도 금세 동나요

용어 한 줄: 아무 생각 없이 Enter만 누르며 AI가 시키는 대로 휙휙 받아쓰는 식의 코딩을 바이브 코딩(vibe coding) 이라고 불러요. 흐름(바이브)에 맡겨 코드를 받아 쓴다는 뜻이에요.

잘못된 기대: "$200 플랜이면 어떻게 쓰든 토큰은 무한이겠지. 그냥 Enter만 막 눌러도 돼."

→ 그렇지 않아요. 아무 생각 없이 마구 돌리면 큰 플랜도 오전에 바닥날 수 있어요.

올바른 이해: "$200 플랜의 여유는 '생각하며 쓸 때' 생기는 여유예요. Enter만 막 누르는 식이 아니라, 어떤 일에 어떤 모델을 쓸지 고르며 쓰면 토큰 걱정이 크게 줄어요."

미니 시나리오: 같은 큰 플랜이라도, 계획은 Opus로 짜고 실행은 Sonnet으로 넘기며 차근차근 쓰는 사람은 하루가 넉넉해요. 반대로 모든 걸 Opus에 맡기고 Enter만 누르는 사람은 점심 전에 막혀요. 플랜이 같아도 결과가 갈리는 건 결국 "어떻게 쓰느냐"예요.

위 "$100", "$200", "약 2시간" 같은 수치는 원서/노트 기준 예시입니다. 최신 요금과 한도는 클로드 코드 공식 문서에서 확인하세요.

잘못된 예 vs 올바른 예

잘못된 예 ($100 플랜): 에이전트 두 개로 Opus를 동시에 돌리기.

→ 한 시간 만에 사용량이 동날 수 있어요.

올바른 예 ($100 플랜): 에이전트 하나만 Opus, 나머지는 Sonnet. 또는 계획만 Opus, 실행은 전부 Sonnet.

미니 시나리오: 작은 플랜인데 빨리 끝내고 싶다고 에이전트 세 개를 Opus로 띄우면, 오전에 사용량이 바닥나요. "꼭지를 몇 개 틀지"를 먼저 정하세요.

스스로 확인

작은 플랜에서 Opus로 연속 작업 가능한 시간이 대략 어느 정도인지 아나요?
에이전트 수가 사용량 소비에 어떤 영향을 주는지 이해했나요?
큰 플랜에서 에이전트를 세 개 넘게 띄울 때 고려할 점을 말할 수 있나요?

섹션 6 — 남은 사용량 가늠하기 (/model 명령과 Default 모드)

막혀본 장면

"내 사용량이 지금 얼마나 남았지?" 하고 찾았는데, 숫자로 딱 알려주는 게 없어서 답답했던 적 있죠?

맞아요. 클로드 코드는 남은 양을 정확한 숫자로 보여주진 않아요.

대신 영리하게 가늠하는 방법이 있어요.

일상 비유부터, 크게

연료 게이지가 없는 차를 생각해 보세요.

남은 기름을 어떻게 알까요?

"주유하고 몇 km 달렸다"로 추정할 수밖에 없어요.

그런데 차에 "연료 절반 남으면 경고등 켜주는 기능"이 있다면 훨씬 낫겠죠?

클로드 코드의 Default 모드 가 바로 그 경고등이에요.

/model 명령 따라 하기

터미널에 이렇게 입력해요.

/model

그러면 모델을 고르는 화면이 나와요.

> 1. Default (recommended)
     Opus를 먼저 쓰다가 일정량 후 Sonnet으로 자동 전환
  2. Opus
     항상 Opus만 사용
  3. Sonnet
     항상 Sonnet만 사용

용어 한 줄: Default 모드 는 "기본 추천" 설정이에요. Opus로 시작했다가 사용량이 어느 정도 차면 알아서 Sonnet으로 바꿔줘요. 연료 절반 경고등과 같아요.

Default 모드가 전환을 알리는 시점

전환 시점 (노트 기준 예시):
  $100 플랜 → 사용량 20%쯤에서 Sonnet 전환 알림
  $200 플랜 → 사용량 50%쯤에서 Sonnet 전환 알림

이 "전환 알림"이 곧 경고등이에요.

알림이 떴다는 건 "Opus 기준으로 이만큼 썼다"는 신호니까, 이걸로 남은 양을 거꾸로 계산할 수 있어요.

비유를 바로 연결

비유	클로드 코드에서	주의
연료 게이지 없음	남은 양을 숫자로 안 보여줌	정확한 잔량 표시는 없어요
절반 경고등	Default 모드의 전환 알림	이 알림으로 잔량을 가늠해요
달린 거리로 추정	전환 시점(%)으로 역산	플랜마다 전환 % 가 달라요

남은 양 거꾸로 계산하기

$200 플랜 예시
  Opus 기준 50%를 쓰면 → Sonnet 전환 알림이 뜸
  이 순간:
   - Opus를 계속 쓰면 → 지금까지 쓴 만큼(약 1배) 더 가능
   - Sonnet으로 바꾸면 → 약 5배 더 사용 가능
     (Sonnet이 사용량을 덜 먹기 때문)

$100 플랜 예시
  Opus 기준 20%를 쓰면 → Sonnet 전환 알림이 뜸
  이 순간:
   - Opus를 계속 쓰면 → 지금까지의 약 4배 더 가능
   - Sonnet으로 바꾸면 → 약 20배 더 사용 가능

위 전환 %, "약 5배", "약 20배" 같은 수치는 원서/노트 기준 예시입니다. 최신 값은 클로드 코드 공식 문서에서 확인하세요. 핵심 원리는 "Sonnet이 Opus보다 사용량을 덜 먹어서 같은 양으로 훨씬 오래 쓸 수 있다"예요.

실제로 쓰는 법

# Opus를 계속 쓰고 싶을 때
/model
→ "2. Opus" 선택
→ 자동 전환을 무시하고 Opus 유지

# 사용량을 아끼고 싶을 때
/model
→ "3. Sonnet" 선택
→ 처음부터 Sonnet만 써서 최대한 오래 사용

# 추천 사용법
→ 평소엔 Default로 편하게
→ 중요한 작업이 남았으면, 전환 알림이 뜰 때 Opus로 강제 선택

잘못된 예 vs 올바른 예

잘못된 예: 전환 알림이 떴는데 그냥 무시하고 계속 Opus로.

→ 정작 중요한 마무리 작업 전에 사용량이 동날 수 있어요.

올바른 예: 알림이 뜨면 "지금 남은 작업이 어려운가?"를 판단.

어려우면 Opus 유지, 아니면 Sonnet으로 바꿔 길게 가요.

미니 시나리오: 알림이 떴는데 남은 일이 단순 코드 작성뿐이라면 망설이지 말고 Sonnet으로. 그 편이 같은 양으로 훨씬 오래 가요.

스스로 확인

/model 명령의 세 가지 선택지를 설명할 수 있나요?
Default 모드가 Sonnet으로 바뀌는 시점이 플랜마다 다르다는 걸 아나요?
전환 알림 후 남은 양을 Opus/Sonnet 각각으로 얼마나 쓸 수 있는지 가늠할 수 있나요?

연습문제

문제 1 — 어떤 모델을 고를까? (기초)

다음 상황에서 Opus와 Sonnet 중 무엇을 고를까요?

(a) 새 프로젝트의 전체 구조 설계

(b) 기존 함수의 변수명만 바꾸기

(d) 계획이 확정된 뒤 단순 API 만들기

정답 보기

(a) Opus — 머리를 많이 쓰는 설계 작업이에요. (b) Sonnet — 단순 반복이라 성능 차이가 거의 없어요. (c) Opus — 어려운 원인 분석엔 Opus가 유리해요. (d) Sonnet — 계획이 있으면 실행 품질은 비슷하고 더 빠르고 효율적이에요.

문제 2 — 세션 시간 짜기 (중급)

작은 플랜 사용자가 9시부터 18시까지 일하고 12시부터 1시까지 점심이에요.

Opus 쓰는 시간을 최대로 늘리려면 세션을 어떻게 짜야 할까요?

정답 보기

1. 8시에 아무 요청을 보내 세션 1을 시작해요. 노트 기준이면 13시까지 유지돼요. 2. 9시부터 12시까지 Opus를 집중해서 써요. 3. 점심시간에도 세션 1은 살아 있어요. 4. 13시에 새 요청으로 세션 2를 시작해요. 18시까지 유지돼요. 5. 13시부터 16시까지 Opus를 집중해서 써요. 6. 16시부터 18시까지는 Sonnet으로 바꾸거나 미팅을 해요. 핵심은 첫 요청 순간부터 시간이 흐른다는 점이에요. (정확한 세션 길이는 공식 문서 확인.)

문제 3 — 남은 양 판단하기 (고급)

큰 플랜 사용자가 Opus로 일하다가 /model을 실행했더니 "Sonnet으로 전환한다"는 알림이 떴어요.

(a) 지금 사용량을 몇 % 정도 쓴 걸까요?

(b) 지금부터 Opus만 쓰면 얼마나 더 쓸 수 있을까요?

정답 보기

(a) 노트 기준 예시로 약 50%예요. 큰 플랜은 50%쯤에서 전환 알림이 떠요. (b) 지금까지 쓴 만큼(약 1배) 더 쓸 수 있어요. (c) 약 5배예요. Sonnet이 사용량을 덜 먹어서, 남은 양으로 훨씬 오래 갈 수 있어요. (수치는 노트 기준 예시이며, 최신 값은 공식 문서에서 확인하세요.)

한눈에 정리

항목	Opus (프런티어 전문가)	Sonnet (고성능 실무자)
잘 맞는 일	설계, 어려운 추론, 난해한 버그	코딩, 대용량 처리, 실무 앱
속도	상대적으로 느림	빠름
사용량 효율	많이 먹음	적게 먹음
언제 쓰나	계획 단계, 막힌 버그	실행 단계, 단순 작업

사용량 아끼는 세 가지 기준	한 줄 요령
일의 형태	계획은 Opus, 실행은 Sonnet
작업 시간	첫 요청 순간부터 카운트 → 집중 직전에 세션 시작
에이전트 수	많이 띄울수록 빨리 닳음 → 꼭지 수 조절

남은 양 가늠: /model → Default 모드의 전환 알림(%)을 경고등 삼아 역산.

다시 강조: 요금·세션 길이·전환 시점·배수 같은 수치는 원서/노트 기준 예시입니다. 최신 값은 반드시 클로드 코드 공식 문서에서 확인하세요.

다음 장 예고

다음 장에서는 클로드 코드를 더 똑똑하게 부려 쓰는 또 다른 방법을 다뤄요. 지금 몰라도 됩니다.

질문

카드를 로딩 중...

답변

클릭하거나 Space를 눌러 뒤집기

0 / 0

학습 진도 0%

← → 이동 Space 뒤집기 R 셔플